Subject: DLSw OUI Header

From: [email-masked]
Date: Tue, 17 Sep 96 12:20:07 EDT

After giving this DLSw OUI header some more thought, I think we need
to add one architected field following the OUI - a message type field.

The reason I say this is that if we do use the DLSw OUI header with an
oui = 0x000000 to indicate messages blessed by the AIW, we are going
to need some common format for part of the messages following the OUI
so that we can distinguish one message from the other.

For instance, if I propose to the AIW a discovery message that has
a message type in the first byte following the oui header and someone
else proposes a different UDP message to the AIW that has message type
in the some other position following the oui header, then we will have
trouble merging proposed UDP messages to the AIW.

I think we may be able to get by with the following OUI header:
   unsb   version               0x32
   unsb   header_length         0x08
   unss   message_length        length of data following OUI header
   unsb   oui[3]                oui
   unsb   message_type          message type of data following

The combination of oui/message_type makes the message unique.
Assume company A creates a proprietary message with their oui and
message_type = 0x01.  If this message is proposed to and approved by
the AIW, it may be necessary to create a new message_type for it
to be unique among the message_types for oui = 0x000000.

This has the added benefit of making the DLSw OUI header an even 8 bytes.

Any thoughts?

Jon Houghton (IBM Corporation)

---

From: Stephane St-Hilaire <[email-masked]>
Date: Tue, 17 Sep 96 13:20:00 PDT

Hi just a few more thoughts,
Even though this message type idea is not a bad one, I don't think it is   
indispensible per say.
Obviously a given organisation will need to standardize where it will put   
a message type style field passed the standardized header (but that can   
be diffrent for each organization really).
So when the AIW starts defining some messages it will have to be   
consistent has to where such a field will be localized to faciliate   
parsing of frames with that OUI value.
The evening to 8 bytes is not a bad thing though but since vendors will   
probably be adding fields to this startup standard header anyways this   
becomes a somewhat lesser issue.

I still think that if a given feature (that could have started up as a   
vendor specific thing) becomes sufficiently interesting for the AIW to   
want to endorse it, that it should favor assigning "real" SSP message   
types (with the normal SSP header) instead of using this "vendor   
specific" provision.

Stephane St-Hilaire (Eicon Technology)

 ----------
From:   
 aiw-dlsw-scalability[SMTP:[email-masked]]
Sent:  Tuesday, September 17, 1996 12:54 PM
To:  stephanh
Subject:  DLSw OUI Header

Any thoughts?

---

From: [email-masked]
Date: Wed, 18 Sep 96 09:14:11 EDT

Stephane, Thanks for the comments - my replies below.

Jon Houghton

>> ------------------------------- Referenced Note ---------------------------
>> Received: from www.raleigh.ibm.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP;
>>    Tue, 17 Sep 96 13:32:23 EDT
>> Received: from localhost.raleigh.ibm.com by www.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03)
>>           id AA11564; Tue, 17 Sep 1996 13:32:01 -0400
>> Date: Tue, 17 Sep 1996 13:32:01 -0400
>> Message-Id: <[email-masked]>
>> Errors-To: [email-masked]
>> Reply-To: [email-masked]
>> Originator: [email-masked]
>> Sender: [email-masked]
>> Precedence: bulk
>> From: Stephane St-Hilaire <[email-masked]>
>> To: [email-masked]
>> Subject: RE: DLSw OUI Header
>> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
>> X-Comment:  DLSw scalability issues
>>
>>

I agree, the AIW will have to standardize where a message type field is
located.
At the last AIW, using an OUI=0x000000 as a method of representing
AIW blessed UDP messages was discussed.  It was brought up that company A
could implement a proprietary UDP message and then propose it to the AIW
to become standard.  If it succeeded, all that may need to change is the
OUI (from the company's OUI to the OUI of 0s).

All I was proposing is that we spend a few moments now standardizing what
part of the message following the OUI we need to to make this conversion
easiest for companies.

>> becomes a somewhat lesser issue.

I agree - this was only mentioned as a side benefit, not a reason for
implementing it.

>> types (with the normal SSP header) instead of using this "vendor

This is the issue we better discuss.  I have been recently investigating
how to do DLSw partner discovery using UDP frames.  The most likely method
would be to occasionally send out a frame to all configured multicast addresses
a short message indicating that a DLSw box is present in the network and
soliciting replies from DLSw partners to find out who else is in the network.

If we choose a method such as this, I would want these messages to be as
short as absolutely possible.  So ... I'd rather have the DLSw UDP OUI header
of length 7 or 8, than the SSP message header of 16 or 72.